Executing DXL from another DXL script

Hi all,

Is there a way to execute DXL script from an other DXL script without using #include.

My need is to updated many modules (same module type) from projects or folders at the same time by running a selected script. I created a GUI to select the script I would like to execute and the type of module on which I would like to apply this script

I thought that runFile or runStr would work but I need a DOORS object to use them. I would like the same but on the current DOORS instance

Thanks

David
SystemAdmin - Fri Nov 26 10:32:04 EST 2010

Re: Executing DXL from another DXL script
llandale - Mon Nov 29 10:39:52 EST 2010

There may be hope with the OLE commands runFile and runStr but I don't do that sorry.

You can use 'eval_', basically like this: 

string NameDxlFile = "c:\MyDxl\MySelectedScript.dxl"
string DxlCode = readFile(NameDxlFile)
if (null DxlCode) {no such file or its empty; return}
 
string ErrMess = checkDXL(DxlCode)
if (!null ErrMess) {print NameDxlFile and ErrMess; return}  // Interpret errors
 
string Results = eval_(DxlCode)
if (!null Results) process Results from the executed code; need to parse for execution errors


But its far more complicated than that. You will need to pass the module names and usually the context of the current script to the evaluated code, which means the evaluated code must be written to accept those parameters; and if so then that code will not run stand-alone. While a few of the cleverest folks here can pass non-text parameters using clever addresses of addresses, you can pass parameters as text as follows:

  

Buffer bufDxlCode
bufDxlCode += "string NameFolderCurrent = " fullName(current Folder) "\n"
bufDxlCode += "string TypeOfModules = " some string indicating type, perhaps "Requirement" "\n"
bufDxlCode += DxlCodeFromFile    // from above
string DxlCodeToRun = stringof(bufDxlCode)
delete(bufDxlCode)
...


Each of the DXL files to run would then use global variables "NameFolderCurrent" and "TypeOfModules" without declaring them, since they get declared above.

Well, after trying to go through all that 10 some years ago, I gave up and decided to deploy common scripts in a library and let each on-demand script include the libraty and do what they want. In this case, you'd need a library routine that accepts the type of module (and perhaps the current folder) and does whatever it does; your on-demand and this big script both call the function. Deploying a library, however, gets REAL sticky in large distributed databases.

Now that I'm thinking about it, let me think out-loud about this alternative: The on-demand script attempts to open a particular file, perhaps "c:\Temp\MyCleverPassedParameters.txt", and if it exists retrieves the folder and module types from the file and procedes to run without a GUI. If the file doesn't exist or contains garbage then it displays a GUI prompting for this information. In any case, delete the file. The over-all clever script reads that info from IT'S GUI and sets it to that particular file, then eval_ the other on-demand script. When eval_ is done it deletes the file (which should already be deleted) again just in case.

 

 

 

  • Louie

 

 

Re: Executing DXL from another DXL script
SystemAdmin - Wed Dec 01 04:26:50 EST 2010

llandale - Mon Nov 29 10:39:52 EST 2010

There may be hope with the OLE commands runFile and runStr but I don't do that sorry.

You can use 'eval_', basically like this: 

string NameDxlFile = "c:\MyDxl\MySelectedScript.dxl"
string DxlCode = readFile(NameDxlFile)
if (null DxlCode) {no such file or its empty; return}
 
string ErrMess = checkDXL(DxlCode)
if (!null ErrMess) {print NameDxlFile and ErrMess; return}  // Interpret errors
 
string Results = eval_(DxlCode)
if (!null Results) process Results from the executed code; need to parse for execution errors


But its far more complicated than that. You will need to pass the module names and usually the context of the current script to the evaluated code, which means the evaluated code must be written to accept those parameters; and if so then that code will not run stand-alone. While a few of the cleverest folks here can pass non-text parameters using clever addresses of addresses, you can pass parameters as text as follows:

  

Buffer bufDxlCode
bufDxlCode += "string NameFolderCurrent = " fullName(current Folder) "\n"
bufDxlCode += "string TypeOfModules = " some string indicating type, perhaps "Requirement" "\n"
bufDxlCode += DxlCodeFromFile    // from above
string DxlCodeToRun = stringof(bufDxlCode)
delete(bufDxlCode)
...


Each of the DXL files to run would then use global variables "NameFolderCurrent" and "TypeOfModules" without declaring them, since they get declared above.

Well, after trying to go through all that 10 some years ago, I gave up and decided to deploy common scripts in a library and let each on-demand script include the libraty and do what they want. In this case, you'd need a library routine that accepts the type of module (and perhaps the current folder) and does whatever it does; your on-demand and this big script both call the function. Deploying a library, however, gets REAL sticky in large distributed databases.

Now that I'm thinking about it, let me think out-loud about this alternative: The on-demand script attempts to open a particular file, perhaps "c:\Temp\MyCleverPassedParameters.txt", and if it exists retrieves the folder and module types from the file and procedes to run without a GUI. If the file doesn't exist or contains garbage then it displays a GUI prompting for this information. In any case, delete the file. The over-all clever script reads that info from IT'S GUI and sets it to that particular file, then eval_ the other on-demand script. When eval_ is done it deletes the file (which should already be deleted) again just in case.

 

 

 

  • Louie

 

 

Thanks for your suggestions Louie, I will take a look at them

David